Skip to content

feat: add metrics to status protocol#5059

Merged
janos merged 10 commits intomasterfrom
status-protocol-with-metrics-text
Mar 28, 2025
Merged

feat: add metrics to status protocol#5059
janos merged 10 commits intomasterfrom
status-protocol-with-metrics-text

Conversation

@janos
Copy link
Member

@janos janos commented Mar 24, 2025

Checklist

  • I have read the coding guide.
  • My change requires a documentation update, and I have done it.
  • I have added tests to cover my changes.
  • I have filled out the description and linked the related issues.

Description

This PR adds metrics to the status protocol for analysing upload and download speeds on different nodes, as well metrics suggested in comments in #5005.

This approach makes it easier to register metrics tat are exposed on the status protocol, by using metrics registry and rendering all metrics as a prometheus formatted strings in a map on a single field of the status protocol's Snapshot message.

Upload and download speed metrics

Upload and download metrics for speed are new ones so that they are measuring only the /bzz uploads and downloads, not /bytes or any other POST methods, making them more specific than content api duration metric which aggregates measurements from all endpoints into one metric.

Additional changes

HeadersExchangeDuration metric now measures only the time of the headers exchange, not a larger scope of functions.

Prometheus go client is upgraded to use a newer encoding type definition. The encoding is actually the same, just the go api has changed.

Open API Spec Version Changes (if applicable)

Motivation and Context (Optional)

Related Issue (Optional)

Screenshots (if appropriate):

LastSyncedBlock uint64 `json:"lastSyncedBlock"`
CommittedDepth uint8 `json:"committedDepth"`
IsWarmingUp bool `json:"isWarmingUp"`
Metrics map[string]string `json:"metrics,omitempty"`
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe metrics should not be exposed through the API? The response is cluttered with encoded metrics data that users can see for their own node on /metrics, and for peer nodes, maybe these metrics are not so relevant. Should we remove this field here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you remove them here, what would be the options then?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The status protocol will still exchange these metrics, but they will not be exposed here, only to be gathered over p2p network, which is sufficient.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The status protocol will still exchange these metrics, but they will not be exposed here, only to be gathered over p2p network, which is sufficient.

I like this approach

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I totally agree. If we really need it, we can expose additional endpoint just for this case. But I don’t see a real reason to do so.

@janos janos marked this pull request as ready for review March 27, 2025 13:42
reserve Reserve
sync SyncReporter
chainState postage.ChainStateGetter
metricsRegistry *prometheus.Registry
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The above protocolVersion has to be incremented for this change, I think.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, thanks.

pkg/api/api.go Outdated
}
}

func (s *Service) downloadSpeedMetricMiddleware() func(h http.Handler) http.Handler {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could add a string argument to the method, which would serve as a label for metrics. This way, we can easily distinguish between 'bzz' and 'bytes' in the endpoint data, because the download speed depends on the logic behind the handlers, and the logic in 'bzz' is more complex than in 'bytes'.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice idea, thanks.

@janos janos merged commit 38eb6e4 into master Mar 28, 2025
15 checks passed
@janos janos deleted the status-protocol-with-metrics-text branch March 28, 2025 16:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants